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(57) Abstract 

A software architecture for use in program 
controlled telecommunications switching ex- 
changes in which application modules are employ- 
ed to provide services to users of a particular com- 
munications applications. Resource modules pro- 
vide specific functional elements of communica- 
tions services to the application modules by having 
access to and control over the exchange hardware. 
Network protocols provide communication be- 
tween the application modules within the exchange 
and interfaces provide communications between 
the resource modules and between application mo- 
dules and resource modules within the exchange. 
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APPLICATION MODULARITY IN TELECOMMUNICATIONS EXCHANGES 

BACKGROUND OF THE INVENTION 
Field of the Invention 

The invention relates to telecommunications exchanges and, more 
5 particularly, to a software architecture for use in a stored 
program controlled telecommunications switching system. 

History of The Prior Art 

In the late 1960s and early 1970s, stored program control (SPC) 
switching systems were designed primarily around the functions 

10 necessary to perform public switched telecommunications network 
(PSTN) service, that is plain old telephone service (POTS) . The 
SPC telecommunications switches used to render these PSTN services 
were virtually all designed with a control architecture which 
separates the parts of the system into functional blocks, each of 

15 which perform a separate function in the completion of a call. For 
example, there are control blocks within a traffic control 
subsystem of the software which perform digit analysis, route 
analysis, call supervision, signalling, etc. Each software block 
performs a certain control function or supervision function within 

20 the hardware which contributes to subscriber call setup, super- 
vision, teardown and billing. 

Over the years, other special features were added to the POTS 
services, such as abbreviated dialing, call waiting, and the like, 
which required the addition of software to the core SPC software 
25 operating the switch in order to render these special services. 

Stored program control telecommunications switches have evolved 
over the years into very sophisticated, special purpose, high 
speed computing machines which include redundant central proces- 
sors for reliability and remote processors for increased speed and 
30 efficiency. A good example of such a switch is the SPC telecom- 
munications switching equipment of the type manufactured by 
Telef onaktiebolaget L M Ericsson and referred to as the AXE 
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exchange , an earlier version of which is disclosed in the article 
by Mats Eklund, et al., entitled "AXE 10 System Description," 
published in Ericsson Review , No. 2, 1976, which is hereby 
incorporated herein by reference. Another example of such an SPC 
5 telecommunications switch is disclosed in U.S. Patent No. 
4,322,843 to H.J. Beuscher, et al. Such switches usually include 
all of the hardware necessary to perform a number of different 
telecommunications services. For example, they can be used as 
local PSTN exchanges, long distance trunking exchanges, private 
10 automatic branch exchanges (PABX) , all primarily by the instal- 
lation of specific SPC software to configure them for the required 
special functions. 

As telecommunications services became more sophisticated over the 
years, new applications for telecommunications exchanges came into 

15 existence which required additional special functionality in the 
software controlling the switch. For example, the growth of 
cellular radio telephone services has required switching exchanges 
to serve as mobile switching centers (MSG) for controlling the 
interconnection of various radio base site controllers (BSC) and 

20 allowing mobile subscribers to be passed from cell to cell within 
the radio network. Similarly, the advent of integrated services 
digital network (ISDN) services has also required special 
functionality within switching exchanges in order to render these 
services to subscribers. While a number of separate specialized 

25 exchanges rendering different services to their respective 
subscribers can be connected together into a communication 
network, it is very expensive, both in terms of redundant hardware 
as well as operation and maintenance personnel to provide discrete 
switches separately programmed with the functionality required for 

3 0 each type of telecommunication service to be rendered. 

One approach to reducing the expenses of a telecommunication 
network is to provide a plurality of different functions in the 
same switch. This involves the adding of additional software 
blocks within the control modules of the switch to provide the 
35 required functionality for the rendition of each service. Such 
functionality may relate to special PSTN related services, 
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business group or centrex type (PBAX) services, ISDN services, MSC 
services and others. The problem with such an approach is that 
while hardware costs are saved by using the same switch for 
multiple functions, the software, and particularly the interaction 
5 of different software blocks with one another, becomes extremely 
complex. For example, the addition of one new function may 
adversely affect or even disable the performance of an existing 
function in a totally unexpected way. As a result, a large part 
of the software development costs encountered with such systems in 

10 use today are connected with trying to anticipate the effect which 
new code added to the system will have upon the existing code and 
the testing and debugging of the overall software system in 
response to the continued addition of new functionality. The 
evolution of such "megasystems" of software has dramatically 

15 increased the costs of adding new upgrades and new functionality 
to existing services and has increased the development time of 
such software to the point that new functions are virtually 
outdated before they can actually be implemented in the switch. 
These are not desirable results for the telecommunications 

20 companies, their customers, or the ultimate subscribers to the 
services. 

Another approach to adding multiple functions to a telecom- 
munications exchange is that of providing multiple processors and 
dividing out the software to spread it across the several proces- 

25 sors. For example, some systems have proposed to have one 
processor execute certain function blocks of software and another 
processor execute other function blocks in order to try and 
decrease the complexity of the software operating within each 
processor. While multiple processor systems may have some 

30 advantages, such as enhanced throughput and call carrying 
capacity, there are distinct disadvantages with such systems. For 
example, where there is a chain of functions required for call 
setup and those functions are spread across multiple processors, 
a fault in one processor can disrupt the entire call setup 

35 process. In addition, the duplication of hardware, such as the 
use of multiple processors, increases not only the cost of that 
hardware but also the cost of other ancillary support and main- 
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tenance functions- These disadvantages of multiprocessor systems 
are present whether the several processors are in the same switch 
and located on a common bus or whether they are located in separate 
switches and interconnected by means of a local area network 
5 (LAN) . 

Still another prior art attempt to achieve multiple functionality 
in a single telecommunications exchange is to simply load multiple 
functionally oriented software systems into the same switch and 
compile them as one such as, for example , the loading of a PABX 

10 software system directly into a local PSTN switch* Such a 
combination includes at least one large disadvantage by requiring 
physical line circuits to perform the interworking between the 
PABX part and the local PSTN part. In addition, there may be other 
conflicts between the functionality of the two different software 

15 systems and certainly no cooperative sharing of separately 
accessed common resources. 

Thus, it would be great advantage to organize the software within 
an SPC telecommunication exchange in a manner which allows 
multiple specific telecommunications applications to be performed 
20 with optimum functionality within the same switch. Such an 
architecture is provided by the system of the present invention. 

SUMMARY OF THE INVENTION 

In one aspect, the system of the invention includes separate 
software blocks defined to include application oriented functions 

25 which are associated together in a single exchange serving 
different applications. The application modules are served by 
resource modules which provide the necessary communication between 
different application modules as well as the necessary hardware 
interactions to perform their respective telecommunications 

30 functions. 

In one aspect the invention includes a software system for 
controlling a stored program controlled telecommunications 
switching exchange which includes a plurality of telecom- 
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munications control modules. Each control module includes 
software for implementing a group of features configured to 
provide telecommunications services for a particular application 
and without regard to configuration of the features for other 
5 applications. The system also includes a plurality of telecom- 
munications resource modules, wherein each resource module 
includes software for implementing common support services which 
are useful by two or more of the control modules, and com- 
munications links between each of the control modules. The links 
10 include network protocols for exchanging information without any 
control module being aware of whether the control module it is 
communicating with is in the same exchange. 

In a further aspect of the invention the resource modules include 
a transaction manager for enabling communications between 
15 respective ones of said control modules and a connection manager 
for controlling the hardware of the exchange in response to 
instructions from the control module. 

In a further aspect the present invention includes a software 
system for controlling a stored program controlled telecom- 

20 munications exchange in which a plurality of application modules 
provide telecommunications services to the users connected to the 
exchange. Each application module include control instructions 
and data for the implementation of a specific telecommunications 
application for the users. A plurality of resource modules 

25 provide certain functional elements of telecommunications 
services to each of the application modules. Each resource module 
has access to and control over the relevant hardware components of 
the exchange necessary for performing the specific functional 
actions required to implement its assigned service elements. Data 

3 0 communications is provided between each of the application modules 
and each other application module and each resource module to 
enable the telecommunications services of each application module 
to be provided to the users without use of the control instruc- 
tions or data of any other application module. 
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In a still further aspect, the invention includes a plurality of 
network protocols for structuring the passage of messages between 
respective application modules so that application modules 
communicate with other application modules without any knowledge 
5 of whether or not the module with which it is communicating is 
within the same exchange* 

BRIEF DESCRIPTION OF THE DRAWINGS 

For an understanding of the present invention, and for further 
objects and advantages thereof, reference may now be had to the 
10 following description , taken in conjunction with the accompanying 
drawings in which: 

FIG. 1 is an illustrative characterization of a prior art software 
system within a local telecommunication exchange; 
FIG- 2 is an illustrative characterization of the prior art 
15 software within a telecommunication exchange which provides for 
multiple application functionality; 

FIG* 3 is an illustrative characterization of the software within 
a telecommunication exchange having the architecture configured 
in accordance with the system of the present invention; 
20 FIG. 4 is a graph illustrating the cost of designing functionality 
into telecommunications software systems; 

FIG. 5 is an illustrative diagram of multiple dedicated telecom- 
munications exchanges interconnected with one another in a 
network; 

25 FIG. 6 is an illustrative diagram of the way in which multiple 
application functionality is incorporated into the software system 
of the present invention; 

FIG. 7 is a block diagram of the overall concept embodied in the 

software system of the present invention; 
3 0 FIGS. 8 and 9 are- block diagrams illustrating communication 

between two exchanges by means of network protocol signalling; 

FIG. 10 is a block diagram illustrating communications between 

application modules through internal network protocols in 

accordance with the system of the present invention. 
35 FIG. 11 is a block diagram illustrating certain aspects of a 

teleconnnunications network related to the system of the present invention; 
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FIG. 12 is a block diagram illustrating a service access module as 
used in the system of the present invention; 

FIG. 13 is a block diagram illustrating certain communications 
aspects of the system of the present invention; 
5 FIG. 14 is a block diagram illustrating certain aspects of 
communication between different exchanges related to the system 
of the present invention; 

FIG. 15 is a block diagram illustrating communication between 
different application modules within the same switching system 

10 incorporating the system of the present invention; 

FIG. 16 is a block diagram illustrating communication between 
different application modules within different switching systems 
incorporating the system of the present invention; 
FIG. 17 is a block diagram illustrating the functional decom- 

15 position of an access application module and a connection manager 
resource module employed within the system of the present 
invention ; 

FIG. 18 is a block diagram illustrating the relationship between 
line functions within access application modules and different 
20 service application modules within the system of the present 
invention; and 

FIG. 19 is a block diagram of access and service application 
modules and supporting resource modules constructed in accordance 
with the system of the present invention; 
25 FIG. 20 is a block diagram of an existing application module and 
a pair of new application modules together with resource modules 
in a software system constructed in accordance with the present 
invention; 

FIG. 21 is a block diagram illustrating communication between 
30 different access and service application modules in the system of 
the present invention; 

FIG. 22 is a block diagram illustrating communication between a 
pair of application modules through a transaction resource module 
within the system of the present invention; 
35 FIG. 23 is a block diagram of an existing application module 
together with a plurality of additional service and access 
application modules together with resource modules in the system 
of the present invention; 
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FIG. 24 is a block diagram of a plurality of hardware and software 
elements illustrating their interrelationship within the system 
of the present invention; and 

FIG. 25 is a block diagram of application modules and a connection 
manager resource module within the system of the present inven- 
tion. 

DETAILED DESCRIPTION 
General Overview 

As discussed above , SPC telecommunications exchanges have evolved 
dramatically over the last several decades. Initially, there was 
a limited amount of functionality incorporated into each exchange 
and the software implementing that functionality was directed 
primarily to the rendition of PSTN local exchange service. 
Referring to FIG. 1, there is shown a small house 11 as a metaphor 
characterizing the software subsystem of a PSTN local exchange 
well known in the prior art. This software has traditionally been 
organized into function oriented blocks, each designed to perform 
a specific functional action and to interact with the other blocks 
to efficiently provide local public switch telecommunication 
network services to the subscribers connected to that exchange. 

As time went on, a number of new telecommunication services were 
developed. These services, such as integrated services digital 
network (ISDN) and public land mobile network (PLMN) f required 
substantially different functionality from that incorporated into 
the software controlling the traditional PSTN exchange. As 
metaphorically illustrated in FIG. 2, the addition of ISDN 
functionality 12 and PLMN functionality 13 to the traditional PSTN 
software functionality 11 required the addition of numerous 
braces, props and software fixes 14 necessary to provide the new 
functionality within the existing framework of conventional PSTN 
based software architectures. The development of such new 
functionality and the incorporation of it into the existing 
structural framework involves a tremendous amount of development 
time and cost, as well as the compromising of numerous features 
and functions in order to ensure that all of the functionality 
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will work together harmoniously in the same exchange. Moreover, 
the design of such "megasystems" of software are reaching the 
point at which the complexity has become so great and the develop- 
ment time so long that this approach is no longer a viable solution 
to the need for additional telecommunications functions. 

The system of the present invention provides a new architectural 
approach to software structures within existing SPC telecom- 
munication exchange hardware and allows the development of 
individual application modules for providing functionality for a 
particular telecommunications application, in a highly efficient 
functionality. As metaphorically represented in FIG. 3, a PSTN 
application module 15 may coexist with an ISDN application module 
16 and a PLMN application module 17 all within the same hardware 
and the same application platform 18. The road 19 by which they 
all communication and interrelate with one another is formed by a 
plurality of resource modules within the software which enable the 
respective application modules to communicate with and relate to 
one another and with respective ones of the resource modules 
through network protocols. That is, the software within v the 
architecture of the present invention is networked within each 
exchange in a manner similar to the way in which discrete exchan- 
ges are networked with one another, as will be set forth in greater 
detail below. 

Referring to FIG. 4, there is shown a graph illustrating the 
current cost of development of successive versions of prior art 
software within a telecommunication exchange. As illustrated, the 
development costs of one issue of a software package 21 includes 
a certain initial cost 22 and involve an increasing amount of work 
as additional functions are added to that software. Ultimately, 
the cost of adding additional functions becomes so prohibitive 
that a particular software package reaches its structural breaking 
point 23 and requires a redesign. Production costs of the next 
edition of the software 24 involves a certain redesign cost, 
preferably undertaken at a cost effective time prior to the 
breaking point of the first software edition 21. As additional 
functions are added to the next edition of the software 24, it too 
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reaches a breaking point 26 and again requires a redesign into a 
third edition 27 and so forth. As can be seen from FIG. 4, the 
amount of work, and thus the costs, of adding additional functions 
to conventional telecommunications software packages becomes more 
expensive the more complex the software becomes. Eventually, the 
software becomes so complex that it is no longer modifiable and 
requires a full redesign in order to continue to perform its 
functions. The system of the present invention provides an 
architecture which dramatically simplifies the inherent necessity 
of upgrading telecommunications software to add new functionality 
and dramatically decreases the cost of such continued growth and 
the expansion of telecommunication services. 

FIG. 5 illustrates a traditional telecommunications network in 
which the objects in the network are the exchanges. A local PSTN 
exchange 31 serves its. local subscribers and is connected via 
trunks 32 to a transit PSTN exchange 33, which is in turn connected 
to an international gateway PSTN exchange 34. For purposes of 
illustration, these exchanges 31-34 are located in a first country 
35 and are connected to exchanges within a second country 3 6 by 
means of international trunks 37 connected to an international 
PSTN exchange 38. The additional exchanges served by the inter- 
national PSTN exchange 38 may include a national ISDN exchange 39 
as well as a national PSTN exchange 40, each of which include a 
plurality of subscribers and are connected by means of trunks 41. 
In addition, the national PSTN 40 exchange may also be connected 
by trunk 41 to a plurality of private PABX exchange networks 42 and 
43 serving their respective subscribers* As illustrated, 
exchanges of such an international network are coupled together by 
means of various networks links and communicate with one another 
by means of network protocols so that they may serve their 
respective areas by providing communications between their 
respective subscribers and other subscribers within the network. 

Referring next to FIG. 6, there is shown an illustration of the 
software system of the present invention in which a single 
exchange 51 can be viewed as incorporating a plurality of separate 
logical nodes and the functionality of those nodes and the 



WO 93/00776 




PCT/SE92/00429 



interconnections between them is incorporated into a single 
exchange 52 containing the software system of the present 
invention. For example, a local PSTN node 53 may be connected to 
an ISDN node 54, both of which are coupled to a private business 
5 group node 55 which is in turn coupled to another private business 
group node 56. The local PSTN node 53 communicates with the 
business group node 55 through a multif requency code (MFC) 
protocol 57, while the ISDN node 54 communicates with both the 
local PSTN node 53 and the private business group node 55 through 

10 the CCITT telephone user part (TUP) protocols 58 and 59. The ISDN 
node 54 may communicate with other ISDN nodes via an integrated 
services user part (ISUP) protocol 61 and the private node 56 
communicates with the private node 55 via a digital private 
network signalling system protocol (DPNSS) 62. Each of the 

15 separate nodes 53-56 include telephone subscribers 63 while the 
private business group node 56 and the ISDN node 54 may also 
include data communications subscribers 64. The way in which each 
of these nodes communicate with other nodes via certain defined 
protocols is reflected in the software architecture of the present 

20 invention which incorporates within a single switch 52^ the 
functionality of the local PSTN node 53 by including a * PSTN 
application module 65. Similarly, the functionality of the ISDN 
node 54 is incorporated into an ISDN application module 66 while 
the functionality of the private business group node 55 is 

25 incorporated into a business group application module 67, each of 
which may communicate with one another via a defined TUP protocol 
68 and with a plurality of common resources 69 via defined 
interfaces 71. The common resources 69 may include switches, load 
supervision (LOAS) , announcement machines (AS AM) , message 

30 transfer parts (MTP) and others. As can be seen in FIG. 6, 
incorporating the functionality within discrete application 
modules in the same switch 52 allows great advantages in the 
simplification of the software into specific application func- 
tions. In the system of the present invention, networking within 

3 5 the software is performed in a similar manner inside the switch 52 
as outside the exchange. 
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Referring to FIG. 7, there is shown a block diagram of the 
components of the software system of the present invention 72 
which comprises a plurality of individual application modules 73 
which are interconnected and coupled both with one another and 
5 with a plurality of resource modules 74. The application modules 
(AMs) 73 communicate with one another and with the resource 
modules (RMs) by means of defined protocols 75 between AMs 73 and 
defined interfaces with RMs 74 which, in effect, create virtual 
switches and enable interaction and networking of the software in 

10 a manner which permits the efficient implementation of discrete 
telecommunication application oriented blocks. This architecture 
provides great advantages in the implementation of the software by 
allowing the tailoring of each application module to the in- 
dividual functionality associated with a particular telecom- 

15 munications application. For example, the functionality of the 
software necessary to implement a business group communications 
application is substantially different to that necessary to 
implement an ISDN application. Dividing the software into 
application oriented modules enables the providing of discrete 

20 telecommunications functions custom configured for particular 
appiications without the necessity of one application^ software 
interacting with software directed to an entirely different 
application functionality, as in the case of the present software 
structures within a single telecommunications exchange. Each of 

25 the application modules can readily communicate with one another 
and may draw upon resource modules within the software which 
provide all necessary interactions with the switch hardware and 
with certain functional services which are available to the 
individual application modules and are common to more than one of 

30 the application modules. In effect, each application module 
comprises a virtual switch or a virtual exchange which thinks that 
it owns the switch hardware and is free to utilize that hardware 
exclusively for its own distinct application oriented functionali- 
ty. This architecture allows the addition of upgrades to the 

35 software and enhancement of the functionality of one application 
module without regard to the affect of those software changes on 
other application modules. Since the exchange is no longer 
controlled by a single body of functionally divided blocks, there 
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is much less likelihood that modifying a functional feature for 
one application will adversely affect the performance of that 
function in another application. 

Application Module Network Specification 

5 General Principles 

When specifying the upper or service level of any application 
module, such as that of a business communication group, the 
services are described as they are seen from outside the system. 
The network level is, however, directed to the services as they 
10 are seen within the application module itself. Two basic prin- 
cipals which should be observed are: 

I A service should appear identical to the user regardless of 
whether the other users involved in the service are on the same or 
other nodes in the network; and 
15 II The user must be able to move from one node to another without 
the necessity of changing the user's number. 

On the network level, the services to be provided are considered 
in terms of the demands they place on the network. Moreover, the 
network level is concerned with the allocation of functionality 
20 within the network and such issues as centralized or distributed 
control within the network. 

In general, the first step is to consider how a telecommunications 
application is specified, which may include specification as a 
development of an already specified service network, e.g., PSTN, 

25 or as a separate service network, e.g., ISDN, as specified by 
C.C.I.T.T. The second step is to identify a reference model for 
the service network, i.e., nodes with specified reference points 
in between, e.g., access and transit nodes with specified 
protocols as reference points. This reference model for a service 

3 0 network will form the base for structuring of the system into AMs. 
In reference models for the nodes, common functionality is 
identified and will form the basis for structuring the system into 
RMs. 
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The Network Model 

In general, a network can be seen as a number of nodes connected 
together by links. In a telecommunications network, the nodes are 
telephone exchanges, subscribers and other peripheral equipment, 
such as computer databases. Traditionally, the controlling nodes 
in a network have been designed to fulfill specific roles, such as 
local exchanges, transit exchanges, mobile subscriber exchanges 
and the like. However, more and more exchange nodes are being 
asked to fulfill more than one role at the same time. This has 
often caused problems in design due to the interaction of the 
different requirements for each role. This is especially true 
with centrex business group communication functions where there 
is a need to see a centrex group as a separate PABX, which is 
isolated from the public switching functions of the system. 

There are telecommunications administrations that specify 
business communications services as a separate service network. 
The reference model for business communications consists of access 
nodes and service nodes. These form the basis for identification 
of the business group AM, the analog access AM, and the digital 
access AM. 

If we consider the nodes we wish to implement in a network as 
logical elements rather than physical elements, it can provide a 
more flexible solution to the problems. Each logical element can 
be seen as a component in an application of which the business 
group application module is merely one example. Other examples 
include the PSTN node , MSC node , etc . , and each appl ication 
supports a number of already defined interfaces, such as MFC, C7, 
DASS1, DPNSS, R2, etc., each of which can be used to interconnect 
different application modules, both internally and externally 
within the physical exchange. Such a logical node oriented 
structure allows the definition and development of application 
modules separately from one another by using defined interfaces. 

It has been suggested that basic telecommunications features 
should be able to be used in any application; however, each 
application has its own distinctive nuances and requirements for 
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each basic feature because of the nature of the communication 
services to be provided* For example, the call diversion feature 
has different specific requirements when implemented for PSTN 
services, business group services, mobile services, and ISDN 
5 services. Thus, if there was only one call diversion feature 
within the system, it would be affected by the addition of each new 
application to the system. 

In accordance with the system of the present invention, each 
application can be designed in the most suitable way with basic 

10 features adapted to that particular application. Each application 
would be a functionally modular unit that can be freely combined 
in one exchange with any number of other applications. In the 
network model, an instance of an application module is called a 
logical node. The logical nodes are all linked together to form 

15 a logical network. 

The network model provides the opportunity to functionally 
decompose the telecommunication applications for complex services 
into several simple application modules. Each module can be 
designed apart from the others and there is no need to be concerned 

20 about the interactions with other modules or the internal workings 
of the other modules. Once objects have been implemented in 
accordance with such networking principles, all services will 
function identically regardless of whether subscribers involved 
are located in the same or in separate nodes and network transpa- 

25 rency of services will have been achieved. 

In applying these principles to the business group services, as an 
exemplary application module, a subscriber does not want to be 
concerned with implementation problems. Implementing networks by 
means of exchanges connected together via links rather than by one 

30 single exchange should not be allowed to degrade the service 
provided. When a call is to be established, the system will be 
informed of the desired destination of the calls by means of a 
string of digits referred to as a directory number. A directory 
number should identify the desired user, not be associated with a 

3 5 special item of user equipment. The subscriber defines the 
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numbering plan to be used within the business group and the 
allocation of internal directory numbers is entirely under the 
subscriber^ control. However, for calls outside the business 
group, the directory number must conform to external convention 
and/or standards and the number plan must also allow for the 
invocation of services and facilities solely by dialing/keying 
digits without ambiguity* 

The generic system level architecture for each application module 
in an exchange, arranged in accordance with the system of the 
present invention, including the exemplary business group being 
discussed herein, employs the shared use of resource modules. The 
access application modules own the line access hardware along with 
some software associated with the interface. They have no 
knowledge or understanding of any of the services supported. The 
resource modules supply general support facilities for all the 
application modules in the exchange. The transaction manager 
resource module provides common facilities to all application 
modules to assist in the transport of messages. It establishes 
links between software components in different application 
modules. The connection resource module owns the switching 
hardware and other pooled resources such as tone receivers, 
mult i junctures and the like, which enables the application modules 
to use those resources and resolves any conflicts and demands for 
the same connection or resource. Other resource modules, such as 
charging support, operation and maintenance support, analysis 
support, time supervision support, and the like, will also be 
employed in assistance of the application modules. The resource 
modules in the present system can be seen as a set of tools wherein 
each application module selects and uses what is needed from the 
tool box for its specific telecommunication application. The 
resource modules are accessed through their interfaces which are 
strictly backwards compatible. The resource modules provide a 
platform to support the design of telecommunications applications, 
i.e., the application modules. The different components of both 
the application modules and resource modules are implemented in 
software blocks. 
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Network Communications 

Since the provision of a telecommunications service necessarily 
involves more than one object, it is necessary to consider how the 
different objects communicate with one another. Such com- 
5 munication is accomplished by means of protocols. 

There are basically three types of communication protocols within 
the architecture: 

I Intra-network communication protocols; 

II Internal protocols; 

III inter-network communication protocols. 

The intra-network protocols involve communication between 
intelligent objects forming part of the same network. Protocol 
use is needed to support all the services provided by its network 
type. The information to be carried between application modules 
includes all of the information that has to be carried between 
separate nodes of the same network type. Therefore, the protocol 
used between application modules is a superset of the protocol 
defined for use between nodes, for example, the lower levels will 
follow the Q900 series recommendations. Since there is currently 
no agreed international standards for the networking of business 
group services as standard, such as the open U.K. DPNSS standard 
of information, flow can be used in such instances. 

The purpose of the internal protocols is to communicate between 
all which objects required in order to support the telephony 
25 services. Such protocols should be capable of conveying: 

I information elements of only internal significance, e.g., 
connection reference point; 

II information elements needed to support a basic telephony 
service; and 

30 III envelopes for information elements of significance only to 
particularly sophisticated signalling systems. 

The inter-network communication network protocol comprises 
standard digital protocols used in telecommunication systems. 
Those such as telephone user part (TUP) , integrated services user 
35 part (ISUP) , national user part (NUP) , etc. can be employed as 
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they are currently used between nodes of a telecommunication 
network today comprising separate switches. A gateway service 
module is used for each type of application module and com- 
municates with the application network for the other network types 
5 via transaction support. 

Software Module Communications 

An important aspect of the system of the present invention is the 
provision of effective communications between the various software 
modules. The communications between application modules is 

10 network oriented while the communications between application 
modules and resource modules is system oriented. The network 
oriented communications is in the form of protocols which are 
specific and well defined rules for controlling information 
transfer between systems, such as telephone exchanges. Protocols 

15 are made up of sequences of messages with specific formats and 
meanings, e. g. , TUP, MFCR2, TCAP, etc. FIGS. 8 and 9 illustrate 
communications between a pair of exchanges according to the CCITT 
signal system no. 7 telephony user part (TUP) signaling protocol. 
FIG. 9 shows that the message transfer part (MTP) corresponds to 

20 approximately layers 1-3 and that the user part (UP) represents 
the remaining layers 4-7. Examples of user parts include tele- 
phony user part (TUP) , integrated services digital network user 
part (ISDN UP) , etc. A protocol that can communicate with other 
exchanges is documented in the form of a protocol description (PD) 

25 which describes all layers 1-7, e.g. , which MTP (e.g. , as exempli- 
fied in the yellow and red books of the C.C.I.T.T.) , the format of 
messages in the user part, coding of information fields, proce- 
dures, etc. 

As discussed above, numerous ones of the existing network 
30 protocols may provide communications between application modules 
in accordance with the system of the present invention. Set forth 
below is a list containing illustrative representative protocols 
which may be employed in particular embodiments of the present 
system along with a reference to the C.C.I.T.T. documentation 
35 thereof which is hereby incorporated by reference herein. 
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PROTOCOL 



C.C.I.T.T. 
RECOMMENDATION NO. 



MFC-R2 
TUP 
I SUP 

D-CHANNEL 
TCAP+SCCP 
CCITT NO. 7 
CCITT NO. 6 



Q.310-Q.490 
Q.72X 



Q.76X 

Q.93X (LAYER 2:Q.92X) 



Q.771-Q.795 
Q.700-Q.716 
Q.251-Q.300 



10 



15 



20 



25 



30 



To illustrate how signalling is performed in an exchange struc- 
tured according to the application modularity concept, FIG. 10 
shows a call going through such an exchange. The application 
module to application module protocol illustrated in exchange B of 
FIG. 10 is an internal type of protocol, i.e., one which is only 
used for communication between application modules located in the 
same exchange. Instead of using the message transfer part (MTP) 
as an end-to-end carrier for layers 1-3, the application module 
protocol makes use of the services offered by the transaction 
manager resource module included within the system of the present 
invention. The application module to application module protocol 
is documented and provides specific formats of messages, coding of 
information fields, and other procedures which are specific to 
that protocol covering layers 4-7. Within these protocols there 
may be a number of specific and different application module to 
application module protocols. 

The differences between an "external" protocol functional 
specification, e.g., ISUP, and a "internal" protocol functional 
specification, e.g., NIIP, include the following: 

1. An external protocol is required to carry the data concerning 
the physical resources involved, e.g. , PCM channels, and how those 
resources are tied to the calls. This requires that operation and 
maintenance procedures and messages are included in order to 
handle these resources, e.g. , blocking, etc. Such is not the case 
for internal protocols, as there are no physical resources being 
used, only logical circuits. 

2 . The length of messages , message structures and coding of 
information may differ between internal and external protocols 
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since they are using different carriers for the layers 1-3, i.e. , 
the MTP services or the transaction services. 

3 . Internal protocols may require additional information 
regarding, for example , session references for charging output, 

5 logic circuit references, etc., that are not required within an 
external protocol. 

Some of the common elements between external and internal 
protocols is that both should be able to satisfy the following: 

1. Both should handle "hostile" environments since things 
10 occasionally go wrong and messages disappear and, therefore, 

require timers to guard against this possibility; 

2. Both should not reflect the internal structure of the 
application modules or the structure of particular manufacturers ' 
hardware ; 

15 3. Neither should assume a specific user of the protocol; and 

4. Both should be "complete" in that they cover all layers 1-7. 

The application module to resource module communication is 
structured in the form of a system interface seen from the 
application module f s point of view, i.e., both elements of the 

20 communication are contained within the same environment, i.e., 
within a common control system. Application module protocols are 
peer-to-peer communication, while application module to resource 
module interfaces are client to server oriented. The user 
interface to a resource module may consist of PLEX signals and the 

25 interface is described in an interface specification. A resource 
module has an identical interface to all AMs/RMs which does not 
allow any unique signals to be sent from an KM. In order to 
perform a service one RM can call upon the services of other RMs. 
FIG. 10 illustrates an example of an application module using the 

30 interface, and therefore, the services from a transaction manager 
resource module. The following points should be observed when 
structuring the layout/look of the resource module interfaces: 

(a) Geographical distribution is not a factor to be considered 
since the resource modules can only be accessed within the same 
35 system; 
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(b) Different manufacturers of equipment are not a factor to be 
considered since the resource modules are all contained within a 
single system; 

(c) Different users are a factor to be considered in that 
5 resource modules are used by different application modules and 

offer different physical services to those application modules; 
and 

(d) A client/server relationship should be maintained between the 
communication with the resource modules. 

10 In documenting the interfaces to be used within the system of the 
present invention, such interfaces can be specified by software 
signals comprising the messages and coding information. Each 
resource module may offer a number of different services , there 
may be a number of different interfaces. For example, the current 

15 design rules in the message transfer parts of conventional 
protocols are good examples of such application module/ resource 
module interfaces. Thus, such interfaces can then be specified 
along with the number of software signals needed to perform the 
service offered by the resource module. One such interfaces may 

20 include the current design rules for using the message transfer 
part services within the common channel signalling subsystem (CCS) 
of the AXE-10 SPC switching system. 

Access Structure Within Application Module Networks 

The term "access" is used herein for the means needed by a user to 

25 reach the user services that are subscribed to in the com- 
munications system. The following discussion will identify these 
means in the form of components or functional entities using an 
object oriented approach. Such an approach supports rapid 
development in the required accesses by allowing a clear separa- 

30 tion between technology and functionality, between access and user 
services, and between traffic handling and operations and 
maintenance. The components identified define an access object 
structure which can be used as a base when defining the access 
product structure. 
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In the access area of the present system there are two access 
application modules , an analog access application module (AAM) and 
a digital access application module (IAM) . In structuring the 
access within the present system certain basic principles are 
5 followed: 

1. Access and user services are separated and, thus, no subscri- 
ber knowledge, subscriber data or user services are part of the 
access application modules. 

2. Physical distribution of the access application modules is 
10 enabled by a network protocol between the access application 

modules and the service application modules. 

3. Physical distribution of switches within the same switching 
system is hidden from the switch users. This is achieved by 
defining a communications interface to a connection manager 

15 resource module which governs the different switches in the 
switching system. 

4. Functionality and technology are separated from one another. 
That is, technology, i.e., the low layer (OSI layer 1-2) functio- 
nality is independent of the high level functionality, such as 

20 user services implemented in the telecommunications network, by 
defining low layer protocols carrying no high level knowledge. 
This enables reuse of the technology by a variety of high level 
functionality. 

Referring now to FIG. 11, it is illustrated that a telecom network 
25 200 includes a number of distinct functional units in order to 
perform its intended purpose. In order to perform a telecom- 
munication service for a user the network 200 includes an access 
component 201, a user service entity (USE) 202 and a network 
service entity (NSE) 203. The user may include either a human 
30 being, an application program or other users which seek to make 
use of the user services that are subscribed to within the telecom 
network 200. The access 201 provides the means needed by the user 
to reach the user services which are subscribed to. The user 
service entity 202 offers and executes services to the user that 
35 are being subscribed to by handling service interactions, charges 
to the entity that has subscribed to the services and the like. 
The network service entity 203 provides information transfer 
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capability and services, for example, provides bearer service and 
capabilities as described by the CCITT in recommendation 1.210. 

Referring next to FIG. 12, there is shown how the service access 
that the service application module 204 employs in the system of 
5 the present invention includes the user service entity 202 as well 
as the network service entity 203. The service application module 
204 is in turn accessed by the user through an access application 
module 201. FIG. 13 shows the different physical access products 
on a switching network level and illustrates that users may access 

10 a switch 205 within a switching system 206 either directly via the 
centrally located subscriber switch (SSS) 207 or remotely through 
a remote subscriber switch 2 08 and a transmission network 209. 
FIG. 14 illustrates that a user may access any number of versions 
of switches 206a-206c within a switching system 206 thrpugh a 

15 transmission network 209 employing standard protocols via an 
independent access product 210, such as an access multiplex 
concentrator (AMC) . Such a product 210 is in itself a homogeneous 
switching system that can serve other homogeneous switches systems 
with access services on a switching network level regardless of 

20 which of the particular switching systems 206a-206c is being 
accessed. 

One reason for having a network protocol to the access application 
modules 204a and 204b is that it will enable physical distribution 
of terminal equipment and lines in the switching network. In this 

25 way, the access application module can be mapped upon a physical 
access product in another switching system than the user service 
entity, as shown in FIGS. 15 and 16. In FIG. 15, a switching 
network 201 includes a switching system 206 comprising an analog 
access application module/digital access application module 

30 226/227 in communication with the user service entity 202 of a 
service application module 204 via a network protocol 229. 
Similarly, in FIG. 16, a switching network 201 includes two 
switching systems 206a and 206b, one of which includes the analog 
access application module/digital access application module 

35 226/227, while the other includes the user service entity 204 
within the service application module 204. In this circumstance, 
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the access module 226/227 communicates with the user service 
entity in the service application module 204 by means of the same 
network protocol 229, this time connected through a transmission 
network 209 rather than directly between the application modules 
themselves. Both switching systems 206a and 206b would also 
include interfaces toward the intermediate transmission network 
209 in order to implement the network protocol 229 and communicate 
therethrough . 

Referring next to FIG, 17, there is shown a functional decom- 
position of the analog/digital access application module as well 
as the decompositions of the line entrance (LE) 231 and a connec- 
tion manager 145, illustrating their close relationship to one 
another • As illustrated, the analog/digital access application 
module 226/227 includes a line entrance (LE) 231 and a line 
handler (I*H) 232. The line entrance 231 comprises a main distri- 
bution frame/ automatic cross connect (MDF/ACC) 23 3, as well as a 
line terminal (LT) 234 and a signalling terminal (ST) 235. A 
connection manager resource module 145, for example, including 
access to a time switch 156g, a remote terminal/ juncture terminal 
156h, a group switch 156j and other hardware 156k, provides 
connection services to both the line handler 232 and to the 
service application module 204. The line entrance 231 provides 
the physical medium that connects the system line 229 to the 
analog access application module/digital access application 
module 226/227. This physical medium handles the conversion 
between the electrical values on the line/system line 229 and the 
internal representation (electrical/logical) in the switching 
system itself. It also subtracts and supports the signalling part 
in the TE/RT interface. That is, it handles roughly layers 1 and 
2 in the OSI protocol for the communication with the TE/RT. The 
functionality of the line entrance 231 is implemented in the 
MDF/ACC 223, the LT 234 (which handles roughly the OSI layer 1) and 
the ST 235 (which handles roughly OSI layer 2) . The line handler 
232 provides the means needed for the line entrance 231 to reach 
the user services in the user service entity 202 of the service 
application module 204. It coordinates signalling and line 
handling activities such as seizure of lines and line channels, 
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and also orders the connection manager 14 5 to set up signalling 
connections between the line terminals 234 and signalling 
terminals 235 . The connection manager 145 handles the physical 
connection, i.e., the paths, in the switching system and in the 
5 process of conducting these activities, handles the various switch 
components such as the time switch 156g, the remote ter- 
minal/juncture terminal 156h, the group switch 156 j and others. 
In the access application module 226/227, low layer protocols are 
defined to the line entrance 231 with respect to line terminals 

10 234 and signalling terminals 235. In this sense, the line 
entrance 231 clearly is a candidate to be implemented as a 
resource module. In such cases, for example, market variations 
would affect mainly the line handler 232. For the connection 
manager, low layer protocols should be defined to the different 

15 switches used, for example, to the time switch 156g and group 
switch 156j, In general, the technology, i.e. , the low layer OSI, 
layer 1-2, functionality should be independent of high level 
functionality such as user services implemented in the telecom- 
munication network. Technology could be separated from the high 

20 level functionality through defining low layer protocols^ (LLP) 
carrying no high level knowledge. These low layer protocols would 
only be affected by changes in technology and, in this way, the 
same technology could be reused by a variety of high level 
functionality. Lower level protocols 236 are used between the 

25 line entrance 231 and the line handler 236 as well as between the 
connection manager 145 and the respective switch elements 156. 

Referring next to FIG. 18, one of the main tasks for the line 
handler 232 within each of the analog access application modules 
226 and digital access application modules 227 is to provide the 

30 means for lines 215a-215g and terminal equipment 213a-213g to 
reach the user services in appropriate user service entities 202a- 
202d within the respective service application modules 121-125. 
In principal, each piece of terminal equipment 213a-213g may be 
connected to different user service entities 202a-202d which means 

35 that the line handlers 232 must be able to read messages on a line 
and terminal equipment basis. In addition, the required channel 
within the line may be indicated, which means that the semantics 
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of the network protocols between the access application modules 
226 and 227 and the user service entities, the line, terminal 
equipment and the channel within the line are needed as keys, as 
illustrated in FIG. 18. It is up to the user service entities 
202a-202d to reject user services not supported by the network 
protocol to a specific line. For example, each type of access 
could have the possible user categories defined in the user 
service entities 202a-202d. 

Referring next to FIG. 19, there is shown a block diagram il- 
lustrating an architectural overview of the way in which an 
exemplary service application module, such as a business group 
(BG) application module 123, interfaces with other application 
modules and resource modules within the resource module platform 
104 in order to complete a call between two users within a business 
group. Within the business group application module 123, each 
call will normally involve three object instances of the user or 
trunk service entity types (USE or TSE) 135 and 136, one for each 
of the two sides of the call. These two instances, 135 and 13 6, 
are linked by an instance of the network service entity (NSE) 137. 
In addition, a number of facilities provided by resource modules 
and accesses will be employed in interfaces with the business 
group application module 123. For example, the A party user 138 
will be linked to the BG module 123 by either a digital access 
application module (IAM) 139 or an analog access application 
module (AAM) 141, while the B party user 142 will also be linked 
to the BG application module 123 by means of a digital access 
application module 143 or an analog application module 144. Each 
of the service entities 135-137 are connected with a plurality of 
different resource modules located within the resource module 
platform 104 . For example, the connection manager resource module 
145, the transaction manager resource module 146 and other support 
manager resource modules 147 provide the necessary support 
services for the user and network service entities 135-137. 
Similarly, the connection and transaction resource modules 145 and 
14 6 are interfaced with analog access resource modules 148 and 
digital access resource modules 149. 
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Within the business group application module 123, the user service 
entity 135 or 136 includes a user agent which communicates with 
the user via the access application modules 139-144, which control 
the hardware interfaces linked to the user's telecommunication 
5 equipment. The user agent of the user service entity includes the 
logic for providing the user's services. Similarly, the trunk 
service entity 135 or 136 includes the logical functions for 
controlling intra-network links. It controls the trunks via the 
trunk line entrances which control the hardware interfaces to 
10 those trunks. The various line entrances are used to provide a 
variety of interface related functions. 

The network service entity 137 is an object type which exists to 
link, for example, two instances of user service entity or trunk 
service entity types in a simple call. It connects to any of them 

15 with the same standard protocol which maps simply into the inter- 
exchange protocol. The user service entity instances originating 
and terminating a call have the same interface to the network 
service entity (NSE) regardless of whether they are on the same or 
separate exchanges. This ensures that services will work in the 

20 same way across a network as across an individual exchange. The 
resource modules 145-147 provide standard transaction and 
connection management functions . The transaction manager resource 
module 146 is optional for communication between service entities 
135-137 and mandatory between separate application modules and 

25 between application modules and accesses 148-149. 

While FIG. 19 illustrates a call taking place between two users or 
trunks within the business group application module, similar 
entities are necessary in calls to be completed between a business 
group application module and another different application module, 

30 for example, the PSTN application module 122. In such a situa- 
tion, an additional entity not specifically shown in FIG. 19, and 
referred to as a gateway services entity (GSE) , is required and 
this object type provides gateways to other network types. Its 
primary concern is with conversion from the internal protocol 

35 within the application module, to the protocol needed to access 
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the other application types. It would also be concerned with 
interworking and charging as a result of this interconnection. 

Referring next to FIG. 20, here is shown an additional overview of 
the system architecture of the present invention which includes a 
5 plurality of application modules, 122-125, and a plurality of 
resource modules 145-149. The application modules 122-125 contain 
the application's specific functionality, such as user services, 
traffic handling and routing. Since each traffic handling 
application module supports a simple call protocol, these modules 
10 are portable between different markets. For example, an app- 
lication module designed for a business group in one country can 
be introduced into an exchange in any other market without the 
need for any additional design effort. Such modularity allows 
very fast introduction of existing applications into additional 
15 markets as they are needed. The resource modules 145-149 provide 
the system common functions, such as call signalling distribution 
between application modules, provided by transaction manager 146, 
switch handling and coordination, provided by the connection 
manager 145, and charging data collection and output, provided by 
20 the charging manager 147. In addition, the resource modules 145- 
149 provide tools for common routines to aid in the design of 
application modules. The nature of the resource modules 145-149 
is such that they provide a good base for the design of network 
services along with the reduction of service interactions. The 
25 subscriber line entrance 151, and trunk line entrance 152, form 
part of both the connection manager resource module 145 and 
transaction manager resource module 146, and provide the inter- 
faces to the outside world as well as the hardware and line 
supervision functions. They do not contain any applications 
3 0 specific or traffic handling functions. This structure not only 
provides a base for reducing the complexity of the application 
modules and the coordination of functionality between them, but 
also a good base for the introduction of new system concepts 
within the software. 

35 As also illustrated in FIG. 20, the system of the present inven- 
tion allows immediate reuse of existing application modules, such 
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as an existing PSTN application 122. For example, a present PSTN 
function providing software system such as the APT 210 08 used in 
the Ericsson AXE exchanges , can be combined with new application 
modules 123 and 125. New system solutions have been thought of in 
the past to be problems of function change, improved restart 
handling and the like; however, the introduction of such new 
system solutions has commonly been rejected due to the need to 
rewrite the majority of the existing software in the system in 
order to implement them. With the present application modularity 
concept, new applications can have such facilities from the outset 
without the need to change existing software. The introduction of 
new application modules is rendered much easier due to the split 
between the pure software application modules and the hardware 
owning resource modules. This is due to the fact that it is most 
often the hardware owning software that causes the greatest 
obstacles to the introduction of new system concepts. 

As exemplified in FIG. 20, new application modules 123 and 125 can 
provide entirely new solutions in functionality alongside existing 
solutions such as the PSTN application module 122. This, in 
20 effect, means that new technologies can be introduced constantly 
without the need to redesign previously designed application 
modules. For example, a version of forlopp restart may be 
included within each of the new application modules 123 and 125 so 
that a fault detected within these modules that would normally 
25 require an entire system restart can be isolated to affect only 
the call or command to which it relates. If such action is not 
enough to clear the fault, then all the software within the one 
particular application module can be restarted and only if both 
these actions failed would an entire system restart be required. 
30 Such new functionality can now be applied within each individual 
new application module and the affect of software faults on 
exchange performance will be greatly reduced. Similarly, new 
application modules, such as BG module 123 and ISDN module 125, 
can be designed in such a way that there is no need to disturb any 
35 existing call, either while it is in speech or being set up, while 
making a function change. In general, at the time of function 
change, all calls that have already been initiated will be handled 
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by the old application module software and subsequent calls by the 
new application module software and, in effect, both application 
modules will be working in parallel for a short period of time. 
In addition, as the hardware is separated from the software of the 
5 application modules, it is possible to detect if a device has been 
left hanging. Such devices can then be released automatically and 
the application software can be reset using forlopp restart 
principles referred to above. 

Referring now to FIG. 21, there is shown a diagram illustrating 
10 the manner in which the transaction resource module 146 provides 
message transfer capability between respective ones of the service 
application modules 122 and 123 and the access application modules 
141 and 144. The transaction resource module 146 includes the 
necessary protocols 130 to enable different application modules 
15 to communicate with one another. 



Referring to FIG. 22, the message transfer capability of the 
transaction resource module 146 is illustrated more specifically 
through its role of providing communication between a first 
application module 122 and a second application module 123. One 
function of the transaction resource module 146 is to hide the 
physical location and type of cooperating application modules from 
one another. From either of the two application modules 122 and 
123, all messages are addressed employing a transaction reference 
140 which is translated by the transaction resource module 146 
into the address of the cooperating application module for which 
the communication is intended. If the two cooperating application 
modules 122 and 123 are located in separate exchanges, then the 
inter-application module messages are passed via trunk line 
entrances to a physical signalling channel connecting the two 
exchanges to one another. In either case, the message sequences 
and message handling is identical whether the two application 
modules 122 and 123 are in the same exchange or not. The trans- 
action protocols preferably include a two-layer structure. The 
lower layer is a generic session protocol that sets up and clears 
down calls between application modules which is then used to carry 
the upper layer or application protocol, which may be analogous to 
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the subsignalling (SS) , telephone user part (TUP) , integrated 
services user part (ISUP) , or mobile application part (MAP) 
protocols* This means that the seizing of records, i.e. , instance 
handling, and basic call handling states can be separated from one 
5 another. In general, access application modules are designed to 
have as little functional influence on traffic handling as 
possible. In principle, they are transparent and simply convert 
the external physical signalling interface into an internal and 
easier to manage form. They do not, however, take care of 

10 additional maintenance functions and the time required when 
physical interfaces are used. Referring next to FIG. 23, 

there is shown a block diagram of a plurality of service access 
application modules 121-126, and access application modules 139- 
144, along with a plurality of resource application modules 145- 

15 147 and 150. As illustrated, an existing PSTN application 122 
could be readily combined with newly designed application modules 
such as the business group module 123. Functionally speaking, the 
service application modules 121-126 provide certain functions 
uniquely configured to their own individual applications for which 

2 0 they are provided. For example, their functionality may include 

digit analysis, routing, and unique telecommunications services 
which are specifically configured for the particular telecom- 
munications application for which they are designed. Each of the 
access application modules 139-144 provide access functionality 
25 within the system and includes functionality such as protocol 
analysis, hardware maintenance, and line maintenance. 

The resource modules illustrated in FIG. 2 3 include the connection 
manager 145, the transaction manager 14 6, a charging resource 
manager 147, and an input/ output (I/O) manager 150, as examples of 

3 0 resource modules. Each of these resource modules provide 

functions which are common to one or more application modules and 
which enable those application modules to provide telecom- 
munication service in accordance with the particular application 
for which they were designed. For example, the connection manager 
35 may provide connection coordination, and interface with both the 
group switch and the subscriber switch, switch maintenance 
functions, as well as multi- junctures (MJS) , as well as key 



BNSDOCIEhcWO 9300776A1 > 



WO 93/00776 




PCT/SE92/00429 



receivers/ code receivers/ code senders (KR/CR/CS) • In addition, 
the connection manager 145 provides access to announcement 
machines as well as tone generators and internetworking units 
(IWUS) . As discussed above, the transaction manager 14 6 provides 
5 interfaces between different application modules and enables 
communication between them. The charging manager 147 provides 
services to the application modules connected with the charging of 
calls in a manner related to common charging elements to each of 
the application modules. In addition, the I/O manager 150 
10 facilitates input/output functions within both the resource 
modules and the application modules. It should be understood that 
the resource modules may call upon the functionality contained 
within the service application modules to provide their own 
support functions. For example, an announcement machine resource 
15 module may provide its services by calling out through a PSTN 
application module to reach the physical announcement machine 
hardware located in a different place from the exchange control- 
ling that resource module. This may apply to other resource 
modules and resources. Referring now to FIG. 24, there is shown 
20 a block diagram illustrating the manner in which the connection 
manager resource module 145 functions to provide access to all 
switching functions within the system. That is, service app- 
lication modules 122 and 123 and access modules 139 and 141 and 
line entrances 148 interface through logical switch objects 154a- 
25 154e within the connection coordination portion 155 of the 
connection manager resource module 145. These logical switch 
objects coordinate the connection with the actual switch hardware 
156, including time switches (TS) , group switches (GS) , remote 
terminals (RT) and juncture terminals (JT) . The switch hardware 
30 156 comprises the standard units now present within SPC telecom- 
munication switches, including, for example, key set receivers 
(KR) 156a, code senders (CS) 156b, code receivers (CR) 156c, 
digital mult i- juncture (DMJ) 156d, announcement machines (AS AM) 
156e and internetworking units (IWU) 156f , each of which is owned 
35 by the connection manager resource module 145, which interfaces 
with the line entrance hardware 153 and 154 in coordination with 
the access application modules 139 and 141 to provide functional 
communication. As can be seen, in order to allow each application 
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module to control connections without the need to coordinate 
between themselves, each application module is given its own 
logical switch objects I45a-145e to control. In order to achieve 
a complete connection in the real switch, these logical switch 
5 objects 154a-154e are linked together via their inlets and outlets 
to provide a picture of the complete speech path. From this 
picture, the real, i.e., physical inlets and outlets can be 
located and these are then connected together using the normal 
subscriber and group switch elements owned by the connection 

10 manager resource module 145. Each logical switch object 154a-154e 
is designed for a specific purpose and thus has a dedicated 
interface which means that operations on it are optimized. For 
most calls, only the access application modules will use logical 
switches for connecting and disconnecting code receivers and 

15 senders. The service providing application module only use simple 
connection objects that perform no real function, but can be 
easily replaced by more complex connection objects, for example, 
conferencing and monitoring if such is required. 

Referring next to FIG. 25, there is shown a group of application 

20 modules 122-125, together with a number of representative resource 
modules which may form one embodiment of the system of the present 
invention. For example, the connection manager resource module 
145 and transaction manager resource module 146 form part of the 
resource module array by providing the essential functions of 

25 communication and connection between and with the application 
modules 122-125. The subscriber line entrance 151 and trunk line 
entrance 152 are associated with each of the connection resource 
module 145 and transaction resource module 146. In addition, 
there is shown a charging manager resource module 147 which 

30 performs charging functions which are common to two or more of the 
application modules. An I/O manager resource module 150 provides 
input/output functions while a statistics manager resource module 
157 provides traffic recording and other statistics measurement 
and management functions. An application module function code 

35 manager 158 provides function code management, while a forlopp 
manager 159 provides forlopp restart functions necessary within 
any of the application modules or within the system as a whole if 
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necessary. An operation and maintenance manager 161 provides the 
traditional operation and maintenance functions. A subscriber 
data manager 162 manages data associated with individual subscri- 
bers which are common to two or more application modules, inclu- 
5 ding a subscriber number manager 165 and a subscriber service 
manager 166. A time event manager 163 provides services asso- 
ciated with the monitoring of certain time oriented functions 
within the system while a route manager 164 provides network route 
management functions. Manager 167 represents numerous other 
10 functions, such as sending/receiving messages by employing 
particular types of signaling, load management, and output 
information management, which could be incorporated within 
resource modules as necessary to provide the service functions to 
two or more application modules. 

15 As can be seen from the above description of the application 
modularity architecture of the present invention, the present 
system proposes numerous advantages and features enabling the 
efficacious growth of future communication services. 

It is thus believed that the operation and construction of the 
20 present invention will be apparent from the foregoing description. 
While the method, apparatus and system shown and described has 
been characterized as being preferred, it will be obvious that 
various changes and modification scan be made therein without 
departing from the spirit and scope of the invention as defined in 
25 the following claims. 
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WHAT IS CLAIMED IS; 

1. In a stored program controlled telecommunications 
switching exchange, a software system for controlling said 
exchange comprising: 

5 a plurality of telecommunications control modules, each 

control module including software for implementing a group of 
features configured to provide telecommunications services for a 
particular application and without regard to configuration of the 
features for other applications; 
10 a plurality of telecommunications resource modules, each 

resource module including software for implementing common support 
services which are useful by two or more of said control modules; 
and 

means for providing communications links between each of said 
15 control modules, said links including network protocols for 
exchanging information without any control module being aware of 
whether the control module it is communicating with is in the same 
exchange . 

2. In a stored program controlled telecommunications 
20 switching exchange, a software system for controlling said 

exchange as set forth in claim 1 which also includes: 

means for providing communications links between each of said 
control modules and said resource modules, said links including 
interfaces for exchanging information therebetween. 

25 3. In a stored program controlled telecommunications 

switching exchange, a software system for controlling said 
exchange as set forth in claim 2 which also includes: 

means for providing communications links between each of said 
resource modules, said links including interfaces for exchanging 

3 0 information therebetween. 

4. In a stored program controlled telecommunications 
switching exchange, a software system for controlling said 
exchange as set forth in claim 1 in which said plurality of 
resource modules include: 
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a transaction manager for enabling communications between 
respective ones of said control modules; and 

a connection manager for controlling selected hardware of the 
exchange in response to instructions from said control modules. 

5 5. In a stored program controlled telecommunications 

switching exchange, a software system for controlling said 
exchange as set forth in claim 4 in which said network protocol 
communications links include a user part and a message transfer 
part and the communications between said telecommunications 
10 control modules in the same exchange enabled by said transaction 
module include said message transfer part* 

6. A software system for controlling a stored program 
controlled telecommunications exchange, comprising: 

a plurality of application modules for providing telecom- 
15 munications services to the users connected to said exchange, each 
application module including control instructions and data for the 
implementation of a specific telecommunications application for 
said users; 

a plurality of resource modules for providing certain 
20 functional elements of telecommunications services to each of said 
application modules , each resource, module having access to and 
control over the relevant hardware components of the exchange 
necessary for performing the specific functional actions required 
to implement its assigned service elements; and 
25 means for providing communications between each of said 

application modules and each other application module and each 
resource module to enable the telecommunications services of each 
application module to be provided to said users without use of the 
control instructions or data of any other application module* 

3 0 7. A software system for controlling a stored program 

controlled telecommunications exchange as set forth in claim 6 in 
which said means for providing communications between each of said 
application modules and each other application module include 
network protocols. 
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8. A software system for controlling a stored program 
controlled telecommunications exchange as set forth in claim 6 in 
which said means for providing communications between each of said 
resource modules and each other resource module and each of said 

5 application modules include interfaces. 

9. A software system for controlling a stored program 
controlled telecommunications exchange as set forth in claim 6 
wherein said application modules include: 

a service application module for providing said application 
10 specific telecommunications services; and 

an access application module for connecting said users to 
said service application modules to receive said services. 

10. A software system for controlling a stored program 
controlled telecommunications exchange as set forth in claim 6 

15 wherein said resource modules include: 

a transaction manager resource module for enabling communi- 
cations between respective ones of said application modules; and 
a connection manager resource module for controlling the 
hardware of the exchange in response to instructions from said 
20 application modules. 

11. A software system for controlling a stored program 
controlled telecommunications exchange as set forth in claim 10 in 
which said means for providing communications between each of said 
application modules and each other application module include 

25 network protocols comprising a user part and a message transfer 
part and the communications between said application modules 
enabled by said transaction resource module includes said message 
transfer part. 

12. A software system for controlling a stored program 
3 0 controlled telecommunications exchange as set forth in claim 6 

wherein said communications providing means includes: 

a plurality of network protocols for structuring the passage 
of messages between respective application modules so that each 
module communicates with every other module without any knowledge 
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of whether or not the module with which it is communicating is 
within the same exchange. 

13 . A method for structuring the software within a stored 
program controlled telecommunications switching exchange located 

5 and forming a node within a telecommunications network to provide 
service to a plurality of users having diverse communications 
applications among them, said method comprising: 

storing within said exchange a plurality of software modules, 
each module containing the control instructions and data for 

10 providing communication services of a particular application type 
and each module acting as a node within said exchange in the same 
way the exchange acts as a node within the network to enable 
changes in network requirements to be mapped into corresponding 
changes within the software nodes of said exchange; and 

15 providing communications between each of said nodes com- 

prising each of said software modules within said exchange and 
each other node within the network. 

14. A method for structuring the software within a stored 
program controlled telecommunications switching exchange located 

20 and forming a node within a telecommunications network as set 
forth in claim 13 in which said step of storing software modules 
within said exchange includes: 

storing a plurality of resource modules, each resource module 
being capable of communicating with each of said software modules 

25 and having access to and control over the relevant hardware 
components of the exchange necessary for performing the specific 
functional actions required to implement assigned service 
elements. 
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